The plugin already uses the official Hytale Maven for the server.jar, as the features I described say. I have a fallback in my code to a launcher file that I intend to expose as a config option, but it is currently not used.

Differences between this and the other PR with the ultradev plugin:

• Complete manifest schema exposed as typed properties instead of blossom-based manual casting.
• Manifest is generated, not parsed from a template (but not specified values in gradle are retained), but full control is exposed via the Gradle config block, including ALL the fields that the server actually parses. Notably, the SubPlugins is also available to nest multiple configs.
• Patchline and arguments for the server are not available, but will be added soon (actually working on a config update right now).
• Using MavenLocal as first in the possible repos to allow local-overwrites to take over for those who test there first.
• The plugin is published on MavenCentral over a custom external Maven.
• Monorepo/Multiloader pattern is supported by using common {} block where you can do directories of common+hytale, or common/foo+common/bar+hytale, or even do multiple hytale projects
• Kotlin support added via a simple useKotlin(), useKotlin("stdlib-dependency-name") or kotlin = "stdlib-dependency-name"
• CurseForge Maven is pre-configured, meaning you can already depend on any mods on CurseForge, and publishing tasks are coming soon.
• Hot reloading and swapping already pre-configured; the users only need to choose a DCEVM-ready JDK when running the automatically generated IDEA run configurations. Meaning you don't need to copy-paste a compiled jar, reboot, and anything like that; you get your changes applied in seconds.
• Devserver is pre-configured with Creative and a Superflat, and already sets the auth store to be Encrypted so that a single login is needed, and the rest is already done.
• The sources are directly linked in the server, so when you edit in the Asset Editor, the changes immediately show up in the source files, no extra steps.
• VSCode run configuration is not generated, but as with all the others, it will come soon with Neovim support.
• On clean, I am not deleting the devserver and all of its progress; that is up to the user, but I could make a cleanDevserver command to make it easier.
• Testing frameworks are already pre-loaded and ready to be used. Examples will be posted in the plugin repo (and on the webpage) over time.

Just quickly added a build script too for those who like to use that, the plugin works in both settings and build ;)
What does the issue-number check want to do?

Hey! We also need to change these guides based on this - I would do it but I'm not experienced with gradle.

https://github.com/HytaleModding/site/blob/main/content/docs/en/guides/plugin/build-and-test.mdx
https://github.com/HytaleModding/site/blob/main/content/docs/en/guides/plugin/setting-up-env.mdx

No worries, I can make the changes ;)

Is #7 Not needed anymore? This pretty much look like a replacement...

Yeah I don't think its needed anymore.

No worries, I can make the changes ;)

@adaliszk did you submit a PR?

@adaliszk did you submit a PR?

@ItsNeil17 preparing it in the evening and will ping you soon

Is it the best idea to be shipping such an opinionated gradle plugin in a template on the most widely known modding site? im all for ease of use, providing a way to run a server and generate sources is one thing, but everything else feels over the top, more like something that would ship with a framework that endorses it rather than a generic template. I feel like sticking as close to vanilla practices as possible while the ecosystem works itself out is the best bet.

On another note, I think you should be able to select a JetBrains Hot-Reload Capable JVM with https://github.com/gradle/foojay-toolchains for the user if im understanding correctly, might be worth looking into.

fwiw ive got a template generator akin to fabrics one in the works at my fork, I can put it up as a draft pr if you want

While the plugin pre-sets a lot of things and is prepared for multiple project templates, rather than writing less sophisticated plugins per setup type, I do not think it goes beyond vanilla, except for not anticipating a split-brain situation with both settings and build scripts both configuring the same thing, but from slightly different angles.

However, you can still write your long, 300-line, verbose vanilla scripts if you wish. If I'm missing any hooks you need, do tell me. I am happy to expose those, as my general goal is not to hide the configuration behind an opinion but to set sensible defaults, especially for those who are picking up Java for the first time. The upcoming changes will focus on configuration and on exposing every single toggle.

The only framework-related feature to me is the agent that ships the more complicated part of hot reloading that the simple DCEVM JVM is not capable of, namely, reloading your actual plugin even when you have dependencies. That is something none of the other plugins can do, as none of them goes beyond a run configuration. The only other alternative is installing a devtools mod that replaces the Hytale plugin manager with its own solution, which, while it may work, will be a burden to maintain and not cause any side effects.

In any case, it is up to the maintainers. I was merely offering a zero boilerplate option that goes in the direction of Stonecutter and Blahaj from Minecraft modding.

Regarding the pages, I am working on them; from what I can see, they would remain mostly the same, though I am not sure about fully dropping the Maven sections, as they are undoubtedly very useful.